Promises can resolve into functions. We’re changing the original/minimal proposal such that value |> await promiseThatResolvesToFunction is a syntax error, right? (Also, what about value |> (await promiseThatResolvesToFunction), value |> (await promiseThatResolvesToFunction, ), etc.?)

Parenthesizing it should work fine, provided that the promise resolves to a function.

@ljharb: But without parentheses, it would be an error, under the current plan (babel/proposals#29 (comment), TC39 presentation), right?

If so, then a supplemental grammar (covering unparenthesized awaited expressions immediately after |>) and an early error (which uses the supplemental grammar) need to also be added, if I understand the situation correctly.

We need to be very careful about requiring parenthesis for the purpose of disambiguating semantics (as opposed to merely disambiguating precedence). It might be a smell.

@zenparsing: It is a smell, but it’s a fundamental part of how Proposal 1 currently addresses await. That’s why smart pipelines accommodate arbitrary expressions—it doesn’t have any silent footguns with required parentheses, though of course it may its own disadvantages.

See also the bottom paragraphs of @tabatkins’ comment at tc39/proposal-smart-pipelines#3 (comment) and also tc39/proposal-smart-pipelines#3 (comment). There may be ways to ameliorate this smell for Proposal 1, as we keep developing all the options. We’re doing it this way for now to compare everything.

Just to be clear, this isn't really intended as the final semantics of the pipeline proposal, but we can be certain that this behavior is not final. This makes await an early error so we can bring the babel plugin's default behavior into alignment with this spec and allows each proposal to solve it as best for them.

@mAAdhaTTah: Making sure sure: Only unparenthesized await right after |> is an early error, right?

We still need to add that supplemental grammar and early error to this pull request. If you are uncertain how to do that, ping me on the Babel slack; or I could try to take care of it later, after I handle some stuff with smart pipelines’ explainer/spec and the presentation. Thanks again for handling this.

To provide some additional context, here is the conversation where @littledan made this suggestion. I'm thinking about the "minimal proposal" as a strawman we can use to compare the tradeoffs of the various proposals.

@js-choi That's the intention, yes.

I think that we should consider making await forbidden at all in the original/minimal proposal’s pipeline bodies.

That is, for the production |PipelineExpression| : |LogicalORExpression|, “It is an early Syntax Error if |LogicalORExpression| Contains await.” (Note that this still allows await inside inner async functions because those hide their inner awaits from the Contains static semantic rule.)

This would make a supplemental covering production unnecessary. It would also prevent the inconsistency of x |> await being invalid in the original/minimal proposal but x |> (await) being valid.

@js-choi x |> (await) desugars to (await)(x), which is a SyntaxError.

I updated to include the early error verbage.

@mAAdhaTTah: Great, though you’ll want to use the Contains static semantic rule, rather than “appears”, and it should go in its own Early Errors subsection. Though this is probably good enough for now for a sketch, so we’ll deal with that later.

If we wanted to be literally subset of the intersection both proposals, we would have to prohibit several other constructs as well. Given that we are not doing that, I don't see why to prohibit any more await cases.